Subject: Re: The problem of the framework draft

From: HJ Sandick <[email-masked]>
Date: Wed, 21 Jan 1998 21:45:58 -0500

Eric,

Good note (as always).

Regards,

Hal

Hal Sandick
IBM, NHD
(919) 254-4614
sandickh@ibmusm20 (internal ibm)
[email-masked] (external)

[email-masked] on 01/15/98 02:01:25 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: Re: The problem of the framework draft

Ohta-san,

We seem to be going around in circles.  Let's try this again.  I believe we
all agree that in order to implement any approach to QoSR, including your
approach,
changes are needed to routing protocols.  It would seem that since your
approach requires similar changes from any routing protocol it shouldn't
matter what order the protocols are changed. (Although, as you have noted,
your approach won't work very well over Distance Vector protocols).

The working group has approached the problem of changes to routing
protocols from a broader perspective, looking at solutions that can work
for a variety of environments (i.e. with and without RSVP).  We believe it
is easier to start with intradomain routing protocols since some of the
scaling requirements might be more relaxed and they might be easier to test
in working networks.  This is the order that things have already been
happening.

We can't prevent, order, or otherwise dictate what other working groups do.
 We can only make suggestions based on what we have learned and out best
judgement.

At 10:33 PM 1/14/98 JST, Masataka Ohta wrote:
>Eric;
>
>> >Why, do you think, we can't start modifying BGP, until we finish
>> >modifying OSPF and RIP?
>>
>> I didn't say that we had to wait to modify interdomain protocols until we
>> were finished with modifying intradomain protocols.
>
>What did you say, then?
>

I said that we want to *start* with the intradomain protocols, not wait
until all of them were finished before working on interdomain protocols!
This is not a completely serialized set of tasks.

>> >We did develop OSPF and BGP simultaneously, because it is the way
>> >to make OSPF and BGP interoperate very well.
>> >
>> While it is very possible to make changes in multiple routing protocols for
>> QoSR in parallel, that is beyond the scope of the QoSR WG.  With the
>> current charter of QoSR and the other routing protocol WGs, the schedule
>> for making any changes to routing protocols is the business of the
>> particular routing protocol WG.
>
>Then, why QoSR WG can say intra-domain should be tried first?
>

We can suggest it and we also observe that this is what has already
happened, witness the work on OSPF QoS routing solutions.

>> Part of the reasoning for starting with
>> intradomain protocols is to gain further experience with QoSR methods in
>> environments where experiments are easier to test and deploy.
>
>As I already stated, the easiest approach to test and deploy QoSR
>is to use a protocol which does not distinguish inter/intra
>domain.
>

While part of your approach does not distinguish between interdomain and
intradomain, it still requires changes to these protocols.  These changes
won't magically happen on their own and they won't happen in exact
parallel.  We can suggest that changes be made in intradomain protocols
first where they can be studied easier.

 Eric

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Jan 98 13:32:09 JST

Hal;

> Good note (as always).

No, it's better neglected. But as you insist...

> until all of them were finished before working on interdomain protocols!

We should better say that we want to *start* with the interdomain protocols,
not wait until a pile of intradomain protocols, which does not scale
nor interoperate with each other nor with scalable interdomain
protocols, are generated.

> happened, witness the work on OSPF QoS routing solutions.

We can't suggest a thing which has already happened, becasue it
has already happened.

We can criticise QOSPF and discourage people repeat the same mistake,
instead.

> parallel.

Yes, it is possible to deply my approach as the interdomain QoSR
protocol. The protocol works intradomain without any magic. No
parallel effort necessary.

What does not happen magically is that intradomain QoSR protocols
interoperate each other.

It may or may not be possible to develop a intradomain protocol
which can interoperate with my QoSR protocol. But, such an approach
can be attempted only after the interdomaiin protocol is fully
defined.

> We can suggest that changes be made in intradomain protocols

As there is already a lot of study on QoSR, such as QoSPF, which
does not work inter-domain, we don't need more.

If there is anything to study about intradomain protocols, it's
the study on how intradomain protocol can interoperate with
the interdomain protocol(s).

That is, the interdomain protocol and its interface to the
intradomain protocol must be provided.

							Masataka Ohta